iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 19
0
Agile

remote agile let you free系列 第 19

遠端人員如何定義自己的產出

  • 分享至 

  • xImage
  •  

很多人對於軟體開發的部分,都會有一種過度樂觀或者是過渡高度評估自己的能力,同時會覺得自己可能某一段程式很快就可以寫完,或者是某一個功能很快就可以直接完成 。

實際上在程式交付的時候,卻又因為種種的因素導致交付功能不如預期,或者是交付的程式碼並不完整。

這個狀況在辦公室內其實很常發生,所以遠端更免不了這種狀況,但是很現實的狀況是,遠端的開發者如果交付的狀況不如預期,很容易會被放大檢視,同時也會被蓋上偷懶的標記。

但是很多時候其實自己都已經盡力了,甚至是加班超時的工作,讓自己極盡所能的在死線之前執行自己的承諾。

這遠端開發的過程中,我們很容易因為其他事物導致自己無法完整的有一段開發專注時間,如果沒有控制好自己的時間很容易就會變的工作時間過度零散。

時間控制得這件事情我們可以稍後再來談談,今天主要是要來談定義產出這件事情

『產出件事情』

每個人的產出其實都有其上限值,還有平均值,甚至是有時候在心情低落時會有一個最小程度交付狀態。

因此並不建議每一個人都將自己的高層次,高交付狀態視為是每日產出的結果,

要怎麼評估自己的最高產出,中間產出,最低產出這三種標準?

實際上,這是需要一段時間的累積還有經驗在開發上的執行,這樣才有辦法師紀衡量自己交付程式的標準。

很多人在評估自己工時的時候,因為遠端的關係可能會把假日的時間,或者休息時間直接評估進去,但就自己的經驗來說其實這樣並不健康,而且對於長期開發狀況這樣子並沒有累積的效益。

過度的壓迫,反而是變成一種短期衝刺,過了衝刺期之後導致自己需要更多的休息時間甚至是恢復期,才有辦法重新的去執行現有的專案內容。

因此我會建議大家要試著從每日的實際開發中找出自己的平均值 ,找到自己的平均值以後再將每日客教父的狀況盡量控制在平均值中間。

當然有的時候會需要超時工作,或者是要超額來進行工作的項目,但這樣的狀態必須要反應給專案負責人知道,同時也不能將這樣的狀態做一個長期性的持續性的運作。

盡量讓這種超時工作的狀態,壓縮在一到兩週以內,這樣才不會導致衝刺期過長和吞噬掉自己的心靈狀況。

所以在評估自己的交付狀況時,還有工作量的時候我會建議每個人都需要找到自己的平均點
,同時在執行一些比較研究行或者是資訊深度高的工作項目時,需要協助請求幫手。

盡量找到先進者可以進行詢問,這樣可以減少自己摸索的時間,同時透過兩兩搭配的模式也比較能夠避免自己一個人重複撞牆的行為發生。

當問題發生的時候或者是程是真的到了某個階段有窒礙難行的時期,可以將問題PO出來甚至是將此問題提出來讓大家進行討論。

畢竟某些時候自己的問題其實反而是別人的專長,透過互相學習互相詢問回答這樣能夠讓自己學習到更多,同時也可以避免自己過於鑽牛角尖的狀況發生。

所以回到這個正題,我們在 回應每日工作量的時候,盡量不要以過度樂觀的方式來進行工作量回報,除非這些項目都已經是你十分拿手或者是已經做過的項目。

不然我會建議就以平均直持續的走下去,讓每天的程式交付都可以有一定的水平,以長跑的心態面對工作內容,好好的建立團隊的信任感,這對於遠端開發會是更有幫助的條件。

希望大家都能夠在合理的工作時間下,完成任務完成專案 。 Happy remote work.


上一篇
誰該定義程式架構?
下一篇
遠端人員的時間控制
系列文
remote agile let you free30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言